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(54) Method of generating a software application 

. (57) . The invention concerns the generation of soft- 
ware application that can be applied to several different 
target platforms. A software application is described by 
two separated, platform independent descriptions of 
said application, a computational description (CD) 
describing the structure and semantic of said applica- 
tion in a platform independent way and an engineering 



description (ED) describing the implementation princi- 
ples of said application in a platform independent way 
Both of said two separated descriptions (CD, ED) are 
used to map the application onto a target platform (TP) 
by means of a respective target platform profile. 
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Description 

This invention concerns a method for generating a 
software application that can be applied to several dif- 
ferent target platforms according to claim 1 , a device for 
generating a software application that can be applied to 
several different target platforms according to claim 1 1 , 
a program module containing a software application 
according to claim 12 and a data processing unit con- 
trolled by a software application according to claim 13. 

Normally, application software is generated and 
encoded closely related to the respective target plat- 
form, on top of which this application will later be exe- 
cuted. The programmer has to take into account the 
application programming interface (API) of the target 
platform and he has to choose the platform dependent 
means and functional principles to implement the exe- 
cution principles of his application. He has therefore for 
example to consider the mechanisms of the operation 
systems (UNIX, Windows NT, ... ) of the target platform. 

This approach has the disadvantage, that the 
description of the application produced by the program- 
mer is dependent on the respective platform and can 
therefore not be automatically be transformed to 
another target platform. If the application has to be exe- 
cuted on another platform, a totally new description of 
the application has to be encoded by the programmer. 

Another drawback of this approach is, that the pro- 
grammer requires knowledge of the platform specif icies, 
which he cannot reuse when he has to encode pro- 
grams for other target platforms. ^ : 

*\Furthe)v : there already exist some standards and 
products (OMG/CORBA, .;. ) that allow an object ori- 
ented, platform independent design of application soft- 
ware. These standards and tools are mainly used for 
generating software applications that are of higher com- 
plexity, which is for example the case in the telecomuni- 
cation field. In such a object oriented design description 
of an application the functions of the application are 
described by a plurality of interaction objects. If the 
application is realized with a CORBA product (CORBA 
= Common Object Request Broker Architecture), the 
specification of the interaction between objects is done 
by means of the IDL language. This description is trans- 
lated to source code written in a programming lan- 
guage, which allows to ensure distribution transparency 
at the programming level. 

But other platform implementation aspects have still 
to be managed by the programmer. Therefore, the draw- 
backs mentioned for the above approach still exists. 

Accordingly, it is a primary objective of the present 
invention to decouple an application from the underlying 
target platform at the design but also at the program- 
ming level. 

This objective is solved by a method for generating 
a software application that can be applied to several dif- 
ferent target platforms according to the teaching of 
claim 1 , a device for generating a software application 



that can be applied for several different target platforms 
according to the teaching of claim 1 1 , a program mod- 
ule implementing a software application according to 
the teaching of claim 12 and a data processing unit con- 

s trolled by a software application according to the teach- 
ing of claim 1 3. 

The underlying idea, this invention is based on, is to 
separate the „what has to be done" from the „hcw it has 
to be done" and describe these two thing's platform 

w independently in two separated descriptions, a compu- 
tational description and an engineering description. 
These two descriptions are then used to map the appli- 
cation onto the respective target platform. 

This new approach has following advantages: 

15 

It ensures the portability of application architecture 
and of the application code. 

• The programmer does not have to take care on the 
20 API of the target platform. 

It is possible to reconfigure an application without 
change the application code. By separation of the 
configuration aspects, that are part of the engineer- 

25 jng description, from the objects and interfaces 
descriptions and code, that are part of the compu- 
tational description, flexibility is gained and you be 
able to change the configuration without having to 
change the objects and interfaces descriptions and 

30 code. 

"* Therefore, by using this new approach the develop- 
ment and evolution costs of ah application and time, to 
market of an application are reduced. 
35 Other advantageous embodiments of the invention 
are described in the subclaims. 

It's especially advantageous to integrate character- 
istics into the computational and in the engineering 
description 

40 

to ensure a good mapping and the use of the most 
adapted mechanisms of the target platform and 
to answer the needs set by the technological field of 
the application, for example to answer telecommu- 
45 nication application needs. 

The characteristics added in both separated 
descriptions have an implementation on the target plat- 
form. The characteristics in the descriptions that 

so requires the knowledge of the platform for the mapping 
and execution are taken into account by generation 
tools and an executive support. This executive support 
takes care of ensuring satisfaction of the characteristics 
and the user does not need to know the platform specif - 

55 ics. 

The present invention will now be described with 
reference to the accompanying drawings, wherein 
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Fig. 1 is a block diagram presenting the architecture 
of a program module according to the invention. 

Fig. 2 is an illustration presenting a part of an engi- 
neering description. s 

Fig. 3 illustrates a flowchart presenting the process- 
ing of a method for generation of a software appli- 
cation according to the invention. 

10 

Fig. 1 shows a software architecture model with an 
application level L1, a support level L2 and a platform 
level L3. 

The application level L1 contains two different, sep- 
arated description, a computational description CD and is 
an engineering description ED. With these both descrip- 
tions the application is described in a platform inde- 
pendent way. 

The platform level contains a target platform TP. 
This target platform has a platform specific application 20 
programming interface. The support level L2 maps the 
application described by the computational description 
CD and the engineering description ED on the target 
platform TP. The support level L2 hides the target plat- 
form specif icies and and maages ist resoures, like distri- 25 
bution, communication, threads.. . 

It is possible that the this mapping is supported by 
tools associated to the support level L2. 

Therefore, . a . program module implementing an 
application has the following architecture: so 

The program module contains the computational 
! description CD andtfe engineering description ED, that 
describe the application; in a platform independent way. 
Further it contains software modules of the support 
level, that provide the mapping of these two descriptions 35 
onto the target platform TP. If the application should be 
transformed to another target platform, only these soft- 
ware modules have to be changed. 

In a preferable embodiment of the invention these 
software modules of the support level are generated 40 
from the two descriptions ED and CD and from a 
respective target platform profile. This is an efficient way 
to generate a well-adapted support level L2. 

In the following an embodiment of the invention is 
described in more detail: 45 

The computational description CD holds the 
abstract notions necessary to describe the structure 
and the semantics of an application in terms that are not 
directly bound to a particular technology. 

In a preferable embodiment the descriptions CD so 
and EC based on an object model. An object model 
embodies the ideas of modularity and data encapsula- 
tion that are useful for structuring and reusability pur- 
poses. 

For creating the computational description CD, the ss 
object has to be abstracted from the direct platform 
issues. A collection of object classes and the relation 
between them has to be described. As example for the 



objects described in the computational description two 
objects OB1 and OB1 are shown in Fig. 1 . 

Objects are described platform independently in 
two different description's ways: An interaction view 
description IVD and a design view description DVD. 

The interaction view description IVD describes the 
interface of an object with the rest of the application, 
that is what service it offers to the rest of the application. 
The interaction view description IVD of an object inter- 
face contains: 

• the definition of supporting types for defining opera- 
tions 

• the signature of each operation that can be invoked 
by clients of an interface of that type 

The interaction view description IVD follows the 
RPC model (RPC=Remote Procedure Call). The type of 
interactions is part of the specification of each opera- 
tion. Two basic types of interactions are supported: 
interrogation or notification. If more application require- 
ment has to be taken into account additional interaction 
types can be introduced. 

As language for describing the object interaction 
view description IVD a language IDL is used. This lan- 
guage IDL is for example the CORBA/IDL language or a 
subset of the CORBA/IDL language. 

The design view description DVD defines the inter- 
nal layout of* the object, that is, the information that 
guides both the implementors of the functional encoding 
and the support software for the support level l_2. 

In the design view description DVD the focus is on . 
the object definition and on its internal structure. This 
includes the interface that the object provides to the out- 
side world. 

In this description it's advantageous to assign to an 
object class one or more non-functional characteristics 
that are relevant to its implementation. Such character- 
istics can be: 

interfaces from other objects that are used, 
supported interfaces, 

administrative interfaces to manage the object life- 
cycle 

execution profile including concurrence and behav- 
ioral characteristics (a execution profile is a prede- 
fined model of execution whose properties are well 
known), 

• quality of service constraints 

• data persistency. 

If the description of such non-functional and quality 
of service properties is sufficiently rich and accurate, 
the choice of an execution profile can be automated. 
Having only a limited set of execution profiles allows to 
master the complexity of the platform programming and 
to ensure the efficiency of the object implementation. 

As language for describing the design view descrip- 
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tion DVD a language ODL is used. As language ODL an 
expand version of the existing language ODL/CORBA 
(ODL=Object Description Language) can be used, that 
contain additional syntax for assigning the above men- 
tioned characteristics. 

To finish the description of an object class, the pro- 
grammer has to code or describe the operations of the 
object class. This is preferably be done after the design 
view description D1 and the interaction view description 
D2 are fully described. By doing this, the computational 
description CD for the objects OB1 and OB2 is finished. 

The characteristics of an object class are ensured 
by the support level L2. Therefore, the programmer has 
not take them into account. He has for example not to 
care about thread management He can concentrate on 
the interactions with the other objects (instance creation 
, operation invocation and instance destruction). 

The engineering description ED addresses the 
describing of the implementation principles of the appli- 
cation. These information's are necessary towards the 
concretization of the computational abstract notions that 
has to be initiated on the target platform. 

Whereas the computational description CD focus 
on individual object design issues, the engineering 
description ED addresses architectural issues and in 
particular ..how" the „whar will be done. The application 
is now viewed as a collection of object instances. The 
engineering description describes for example issues of 
placement (what will .be local, what will be remoted) or 
grouping of service instances- into units of execution 
resource allocation (that will be later mapped to platform 
cdncepts such as processes). ' 
' i Following .main notions are used for describe the 
engineering description: 

A capsule is an abstraction of a resource provision 
unit. Object instances are grouped into capsules. 
Characteristics are assigned to a capsule that 
describe its behavior. These characteristics are for 
example the assignment of engineering threads 
and queues. 

A node represents the entity that actually provides 
physical execution resources, it refers to a single 
computer or station 

Recovery: in case the application is not able to pur- 
sue its computation because there is for example a 
system or an applicative problem, parameters are 
assigned that initiating the recovery of a part of it. 
The smallest unit of recovery is a capsule. 

• An object instance can be statically or dynamically 
created activated deactivated and destroyed 
through a factory service. 

Figure 2 shows an example of a part of such an 
engineering description. It shows 3 capsules C1 to C3, 



containing object instances Ol. The object instances Ol 
are distributed into the capsules C1 to C3 and each of 
the capsules C1 to C3 are dimensioned according to the 
implementation principles of the application. 

5 The capsule C1 is assigned to the handling of a 
call. It contains several different interaction object 
instances directed to signaling, charging, call managing 
and CNX managing. The capsules C2 and C3 contains 
several subscriber object instances. 

10 Further, according to implementation principles of 
the application the above mentioned characteristics and 
parameters are assigned to the capsules C1 to C3 and 
an assignment is specified that map the capsules C1 to 
C3 to the available nodes. 

is The engineering description ED is described by 
means of a configuration description language CDL 

The applicative objects that have been described 
by the computational description CD are mapped onto 
the target platform TP. Both descriptions, the computa- 

20 tional description CD and the engineering description 
ED are used to choose the most suitable mechanisms 
of the target platform. There is not only an intermediate 
layer, the support layer L2, put on top of the platform, 
but this intermediate layer is generated from the two 

25 descriptions CD, ED in such a way, that the best advan- 
tage's for its regarding application characteristics is 
taken. The use of platform functionality and inner mech- 
anisms of the platform are completely controlled by the 
support level 12. ^ 

30 Advantageous, the translation from the computa- 
- tional description CD and the engineering description 
' ED to the platform programming interface of the target 
. : platform TP is done at software production time and not 
at runtime. This is done by using a respective target 

35 platform profile well suited to the target platform TP. 

Because of the complete description of the seman- 
tic, structure and implementation principles, mapping 
rules can be precisely defined for every target platform 
and can be stored in a target platform profile. 

40 The support level comprising a generic runtime 
GM, a plurality of object support modules OS1 and OS2 
and a capsule support module CS. 

The object support modules OS1 and OS2 and the 
capsule support module CS make the link between the 

45 two descriptions of ED and CD and the generic runtime 
GM. 

The object support modules OS1 and OS2 are gen- 
erated from the computational description CD. The sup- 
port modules OS1 and OS2 take care, that the 
so characteristics of the object class are respected and 
implemented on the target platform TP. 

The capsule support module CS is generated from 
the engineering description ED. It takes care on the 
implementation principles and makes the mapping of 
55 these implementation principles on platform concepts 
like processes and software components and to gener- 
ate automatically the respective services. 

The generic runtime GM is independent from the 
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application. It includes operations like communication, 

the thread management, It uses the target platform 

specificity's to manage the distribution, the platform 
resources, the communications between object 
instances, the recovery, .. . 5 

The runtime GM implements the execution profiles 
specified in the design description of the objects, it 
includes the instance concurrence control, the thread 
management inside a capsule and the choice of internal 
communication mechanisms. Further, the runtime GM 10 
makes the interfaces with the platform, the manage- 
ment of the instances life-cycle, the management of the 
data persistency and of the recovery of active instances 
in case of crash failure. 

The generation of a platform independent applica- is 
tion is now demonstrated according to Fig. 3. 

Fig. 3 shows 4 application description steps D1 to 
D4, 3 compilation steps COMP1 to COMP3, the support 
modules CS, OS1 and OS2 and two mapping profiles 
MP1 and MP2. 20 

In the description steps D1 and D2 the design view 
description DVD and interaction view description IVD of 
the objects of the application are inputted and memo- 
rized. 

In the description step D3 the engineering descrip- 2s 
tion ED is inputted and memorized. 

The memorized design view description DVD and 
interaction view description IVD of the objects of the 
application are translated, after performing consistency 
checks, in the compilation step COMP1 into a program- 30 
ming language.- In the description step D4 ^description 
of the operations.of the objects is inputted. This descrip- 
■ tion is written in said programming language and filled in 
the position determined by the translated design view 
description DVD and interaction view description IVD of 35 
the objects. This detail computational description CD is 
then memorized. 

In the compilation step COMP2 the engineering 
description ED is translated, after performing consist- 
ency checks, into the support module CS that contain all 40 
material required to build up the application: source 
files, make files or equivalent. 

In the compilation step COMP3 the computational 
description CD is translated into the support modules 
OS1 and OS2. This compilation steps takes into 45 
account the mapping profiles MP1 and MP2. The map- 
ping profile MP1 is the runtime GM and the mapping 
profile MP2 are the target platform liberies. 

Claims so 

1 . A method for generating a software application that 
can be applied to several different target platforms, 
said method comprising the steps of: memorizing of 
two separated, platform independent descriptions ss 
of said application, a computational description 
(CD) describing the structure and semantic of said 
application in a platform independent way and an 
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engineering description (ED) describing the imple- 
mentation principles of said application in a plat- 
form independent way and using of both of said two 
separated descriptions (CD, ED) to map the appli- 
cation onto one of said several target platforms (TP) 
by means of a respective target platform profile. 

2. The method according to claim 1 further including 
the step of memorizing the computational descrip- 
tion (CD) and the engineering description (ED) 
based on abstract notions. 

3. Hie method according to claim 1 further including 
the step of memorizing the engineering description 
(ED) as a description of interacting objects. 

4. The method according to claim 1 further including 
the steps of memorizing of one or several non-func- 
tional characteristics in the computational descrip- 
tion (CD) and using that characteristics for the 
mapping and the selection of the best adapted 
mechanisms of said target platform (TP). 

5. The method according to the claims 3 and 4 further 
including the step of memorizing a description 
(DVD) of a plurality of said interacting object 
respectively assigned one or several of said non- 
functional characteristics describing the non-func- 
tional behavior.of the respective interacting object. 

6. The method according to claim 1 further including • 
the steps of memorizing of one or several charac- 

• teristics in the engineering description (ED) and; 
using said characteristics for the mapping and the 
use of the best adapted mechanisms of said target 
platform (TP). 

7. The method according to the claims 3 and 6 further 
including the step of memorizing a description of 
grouping of instances of said interacting objects 
(Ol) and a description of an assignment between a 
group of object instances (C1 to C3) and a specific 
group characteristic. 

8. The method according to claim 1 further including 
the step of generating one or several executive sup- 
port modules (OS1 , OS2, CS) out of the computa- 
tional description (CD) and the engineering 
description (ED), which controls the execution of 
the application together with a generic runtime 
(GS). 

9. The method according to claim 1 further including 
the step of generating separated executive support 
modules (OS1, OS2; CS) out of the computational 
description (CD) and the engineering description 
(ED), respectively, which link the computational 
description (CD) and the engineering description 
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(ED) with the generic runtime (GS), respectively. 
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10. The method according to the claims 4, 6 and 8 fur- 
ther including the step of generating the executive 
support modules (OS1, OS2, CS) in such a way s 
that the executive support modules (OS1, OS2, 
CS) selects by means of the generic runtime (GS) 
the proper mechanisms of the target platform (TP) 

to satisfying the characteristics of the application 
described in the computational description (CD) 10 
and in the engineering description (ED). 

11. A device for generating a software application that 
can be applied to several different target platforms, 
said device containing first inputting means for is 
inputting a computational description (CD) describ- 
ing the structure and semantic of said application in 

a platform independent way, second inputting 
means for inputting an engineering description (ED) 
describing the implementation principles of said 20 
application in a platform independent way, memory 
means for memorizing said computational descrip- 
tion and said engineering description as two sepa- 
rated, platform independent descriptions of said 
application, and generating means for generating 25 
by means of both of said two separated descrip- 
tions (CD, ED) and of a target platform profile an 
executive support (OS1, OS2, CS, GS) that maps - 
the application onto a respective one of said several 
target platforms (TP). j30 

12. :Aprogram module implementing a software -appli- 
cation, said program module containing two sepa- 
rated, platform independent descriptions of said 
application, a computational description (CD) 35 
describing the structure and semantic of said appli- 
cation in a platform independent way and a engi- 
neering description (ED) describing the 
implementation principles of said application in a 
platform independent way, and containing mapping 40 
means (OS1 . OS2, CS1 , GS) for mapping the appli- 
cation described by said two separated descrip- 
tions (CD, ED) onto a target platform (TP). 

13. A data processing unit controlled by a software 45 
application, said data processing unit containing 
two separated, platform independent descriptions 

of said application, a computational description 
(CD) describing the structure and semantic of said 
application in a platform independent way and a so 
engineering description (ED) describing the imple- 
mentation principles of said application in a plat- 
form independent way, and containing mapping 
means (OS1 , OS2, CS1 . GS) for mapping the appli- 
cation described by said two separated descrip- ss 
tions (CD, ED) onto a target platform (TP). 
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